Network Working Group R. Braden 
Request for Comments: 1127 ISI 
October 1989 


A Perspective on the Host Requirements RFCs 
Status of This Memo 


This RFC is for information only; it does not constitute a standard, 
draft standard, or proposed standard, and it does not define a 
protocol. Distribution of this memo is unlimited. 


Summary 


This RFC contains an informal summary of the discussions and 
conclusions of the IETF Working Group on Host Requirements while it 
was preparing the Host Requirements RFCs. This summary has several 
purposes: (1) to inform the community of host protocol issues that 
need further work; (2) to preserve some history and context as a 
starting point for future revision efforts; and (3) to provide some 
insight into the results of the Host Requirements effort. 


1. INTRODUCTION 


A working group of the Internet Engineering Task Force (IETF) has 
recently completed and published a monumental standards document on 
software requirements for Internet hosts [RFC-1122, RFC-1123]. This 
document has been published as two RFC’s: "Requirements for Internet 
Hosts -- Communication Layers", referred to here as "HR-CL", and 
"Requirements for Internet Hosts -- Application and Support", 
referred to here as "HR-AS". Together, we refer to them as the Host 
Requirements RFCs, or "HR RFCs". 


Creation of the Host Requirements document required the dedicated 
efforts of about 20 Internet experts, with significant contributions 


from another 20. The Host Requirements working group held 7 formal 
meetings over the past 20 months, and exchanged about 3 megabytes of 
electronic mail. The HR RFCs went through approximate 20 distinct 
drafts. 


This group of people struggled with a broad range of issues in host 
implementations of the Internet protocols, attempting to reconcile 


theoretical and architectural concerns with the sometimes conflicting 
imperatives of the real world. The present RFC recaps the results of 


this struggle, with the issues that were settled and those that 
remain for future work. This exegesis has several goals: 
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(1) to give the Internet technical community some insight into the 
results of the host requirements effort; 
(2) to inform the community of areas that need further work; and 


(3) to preserve some history and context of the effort as a starting 
point for a future revision. 


1.1 GOALS OF THE HOST REQUIREMENTS RFCs 
The basic purpose of the Host Requirements RFCs is to define the 
requirements for Internet host software. However, the document goes 
far beyond a simple prescription of requirements, to include: 
(a) a bibliography of the documents essential to an implementor; 
(b) corrections and updates to the original standards RFC’s; 
(c) material to fill gaps in the previous specifications; 


(d) limitations on implementation choices, where appropriate; 


(e) clarification of important issues and the intent of the 
protocols; and 


(£) documentation of known solutions to recurring problems as well 
as implementation hints. 


Broadly speaking, the Host Requirements working group started from 
the following goals for Internet host software: 


(1) Interoperability 

(2) Extensibility 

(3) Functionality 

(4) Efficiency 

(5) Architectural Purity 

Of these, interoperability was clearly preeminent, while 
architectural purity had the lowest priority. It is more difficult 
to assign relative importance to extensibility, functionality, and 


efficiency, as it varied from one topic to another. 


At a more technical level, the working group pursued a set of general 
goals that included the following: 
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* Discourage hosts from unexpectedly acting as gateways. 

o Discourage the use of bad IP addresses. 

* Eliminate broadcast storms. 

* Discourage gratuitous Address Mask Reply messages. 

* Facilitate the use IP Type-of-Service for routing and queueing. 

i Encourage implementations of IP multicasting. 

Ki Encourage TCP connection robustness. 

kj Encourage (mandate!) implementation of known TCP performance 
enhancements. 

ii Encourage user interfaces that support the full capabilities of 


the protocols. 


* Encourage more complete implementations of FTP. 

* Encourage robust mail delivery 

7 Discourage the source-routing of mail in the Internet. 
X Encourage error logging. 


In addition to these general technical goals, the working group 
decided to discourage the use of certain protocol features: e.g., the 
IP Stream Id option, ICMP Information Request and Reply messages, the 
RFC-795 TOS mappings, WKS records in the Domain Name System, and FTP 
Page structure. 


The HR RFC tries to deal only with the software implementation, not 
with the way in which that software is configured and applied. There 
are a number of requirements on Internet hosts that were omitted from 
the HR RFC as administrative or configuration issues. 


The HR RFCs contain many, many detailed requirements and 
clarifications that are straightforward and (almost) non- 
controversial. 


Indeed, many of these are simply restatements or reinforcement of 
requirements that are already explicit or implicit in the original 
standards RFC’s. Some more cynical members of the working group 
refer to these as "Read The Manual" provisions. However, they were 
included in the HR RFCs because at least one implementation has 
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failed to abide by these requirements. In addition, many provisions 
of the HR RFCs are simply applications of Jon Postel’s Robustness 
Principle [1.2.2 in either RFC]. 


However, not all issues were so easy; the working group struggled 
with a number of deep and controversial technical issues. Where the 
result was a reasonable consensus, then definite, firm 
recommendations and requirements resulted. We list these settled 
issues in Section 2. Section 2 also lists a number of areas where 
the HR RFCs fill gaping holes in the current specifications by giving 
extended discussions of particular issues. 


However, in some other cases the working group was unable to reach a 
crisp decision or even a reasonable consensus; we list these open 
issues in Section 3. Future discussion is needed to ascertain which 
of these issues really do have "right answers", and which can 
reasonably be left as implementation choices. Section 4 contains 
some other areas that the working group did not tackle but which need 
further work outside the context of the HR RFCs (although the outcome 
may be reflected in a future revision). Finally, Appendix I lists 
specific issues for consideration by a future HR RFC revision effort, 
while Appendix II lists the issues that are relevant to a revision of 
the Gateway Requirements RFC. 


It should be noted that this categorization of issues is imperfect; a 
few issues appear (legitimately) in more than one category. 


For brevity, we do not attempt to define all the terminology or 
explain all the concepts mentioned here. For those cases where 
further clarification is needed, we include (in square brackets) 
references to the corresponding sections of the HR RFCs. 

2s SETTLED ISSUES 


Here are the areas in which the Host Requirements working group was 
able to reach a consensus and take a definite stand. 


= ARP Cache Management [Chie 23.215] 

Require a mechanism to flush out-of-date ARP cache entries. 
= Queueing packets in ARP [Ch 23r 22] 

Recommend that ARP queue unresolved packet (s) in the link layer. 
= Ethernet /802.3 Interoperability ER 2'..3%:34] 


Impose interoperability requirements for Ethernet and IEEE 802.3 
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encapsulation. 

Š Broadcast Storms [CL 2.4. 322324 
Require many provisions to prevent broadcast storms. 
In particular, require that the link-layer driver pass a flag to 
the IP layer to indicate if a packet was received via a link- 
layer broadcast, and require that this flag be used by the IP 
layer. 


z Bad IP addresses 


Include numerous provisions to discourage the use of bad IP 
addresses. 


eZ Address Mask Replies [CL 3.2.2.9] 
Discourage gratuitous ICMP Address Mask Reply messages. 
= Type-of-Service 


Include various requirements on IP, transport, and application 
layers to make Type-of-Service (TOS) useful. 


- Time-to-Live [CL 3.2.1.7] 
Require that Time-to-Live (TTL) be configurable. 
- Source Routing [CL 3.2.1.8 (e) ] 


Require that host be able to act as originator or final 
destination of a source route. 


z IP Multicasting [CL 3437] 
Encourage implementation of local IP multicasting. 

= Reassembly Timeout [CL 343224] 
Require a fixed reassembly timeout. 

a Choosing a Source Address BEINE EEE ASES EE E E ESE 457.482.3811 
Require that an application on a multihomed host be able to 
either specify which local IP address to use for a new TCP 


connection or UDP request, or else leave the local address 
"wild" and let the IP layer pick one. 
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TCP Performance [CL 4.2.12.15, 4.2.3.1-4] 

Require TCP performance improvements. 

TCP Connection Robustness [CL 4527.32.55: 44:223'09)] 
Encourage robustness of TCP connections. 

TCP Window Shrinking [CL 4.2.2.16] 

Discourage the shrinking of TCP windows from the right. 
Dotted-Decimal Host Numbers [AS 2.1] 


Recommend that applications be able to accept dotted-decimal 
host numbers in place of host names. 


Telnet End-of-Line [AS 3.3.1] 

Include compatibility requirements for Telnet end-of-line. 
Minimal FTP [AS 4.1.2.13] 

Enlarge the minimum FTP implementation. 

Robust Mail Delivery [AS "5.32, 5.3.4, GaL A] 


Recommend the use of long timeouts and of alternative addresses 
for multihomed hosts, to obtain robust mail delivery. 


Source-Routing of Mail [AS 5.2.6, 5.2.16, 5.2.19] 

Discourage the use of source routes for delivering mail. (This 
was one of the few cases where the working group opted for the 
architecturally pure resolution of an issue.) 


Fully-Qualified Domain Names [AS 5.2.18] 


Require the use of fully-qualified domain names in RFC-822 
addresses. 


Domain Name System Required [AS 6.1.1] 
Require that hosts implement the Domain Name System (DNS). 
WKS Records Detracted [AS 2.2, 5.2.12, 6.1.3.6] 


Recommend against using WKS records from DNS. 
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= UDP Preferred for DNS Queries [AS 6.1.2.4, 6.1.3.2] 
Require that UDP be preferred over TCP for DNS queries. 
= DNS Negative Caching [AS 6.1.3.3] 


Recommend that DNS name servers and resolvers cache negative 
responses and temporary failures. 


Finally, here is a list of areas in which the HR RFCs provide 
extended discussion of issues that have been inadequately documented 
in the past. 


- ARP cache handling FEE 2.35. 2:5 1] 

= Trailer encapsulation FET 2a] 

- Dead gateway detection algorithms Gh. 33.124] 
= IP multihoming models ECLA: 344] 


(Note that this topic is also one of the significant contentious 
issues; see the next section.) 


= Maximum transmission unit (MTU and transport-layer maximum- 
segment size (MSS) issues [CL 33427 .3%.3435. S044. Aaly 
42.26) 


aay TCP silly-window syndrome (SWS) avoidance algorithms 
[CL 4.2.3 23, 442.354) 


oe Telnet end-of-line issues [AS 3.3.1] 

oe Telnet interrupt/SYNCH usage [AS 3.2.4] 

Š FTP restart facility [AS 4.1.3.4] 

- DNS efficiency issues [AS 6.1.3.3] 

- DNS user interface: aliases and search lists [AS 6.1.4.3] 
There are some other areas where the working group tried to produce a 


more extended discussion but was not totally successful; one example 
is error logging (see Appendix I below). 


Braden [Page 7] 


RFC 1127 Perspective on Host Requirements October 1989 


3. OPEN ISSUES 


For some issues, the disagreement was so serious that the working 
group was unable to reach a consensus. In each case, some spoke for 
MUST or SHOULD, while others spoke with equal fervor for MUST NOT or 
SHOULD NOT. As a result, the HR RFCs try to summarize the differing 
viewpoints but take no stand; the corresponding requirements are 
given as MAY or OPTIONAL. The most notorious of these contentious 
issues are as follows. 


= Hosts forwarding source-routed datagrams, even though the hosts 
are not otherwise acting as gateways ECL B3] 


= The multihoming model [CE 3:534] 


= ICMP Echo Requests to a broadcast or multicast address 


[CL 3.2.2.6] 
- Host-only route caching [CL 32.3 hss] 
= Host wiretapping routing protocols [6h<3:.. 31.24] 


= TCP sending an ACK when it receives a segment that appears to be 
out-of-order [CL 4.2.2.21] 


There was another set of controversial issues for which the HR RFCs 
did take a compromise stand, to allow the disputed functions but 
circumscribe their use. In many of these cases, there were one or 
more Significant voices for banning the feature altogether. 


5 Host acting as gateways [CL 3.1] 

= Trailer encapsulation PCL, 2.2364] 

Š Delayed TCP acknowledgments [ET 422503 2] 

- TCP Keep-alives [CL 4.2.3.6] 

- Ignoring UDP checksums [CL 4.1.3.4] 

= Telnet Go-Aheads [AS 3.2.2] 

= Allowing 8-bit data in Telnet NVT mode [AS 3.2.5] 
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4. OTHER FUTURE WORK 


General Issues: 


(1) 


(2) 


Host Initialization Procedures 


When a host system boots or otherwise initializes, it needs 
certain network configuration information in order to communicate; 
e.g., its own IP address(es) and address mask(s). In the case of 
a diskless workstation, obtaining this information is an essential 
part of the booting process. 


The ICMP Address Mask messages and the RARP (Reverse ARP) protocol 
each provide individual pieces of configuration information. The 
working group felt that such piecemeal solutions are a mistake, 
and that a comprehensive approach to initialization would result 
in a uniform mechanism to provide all the required configuration 
information at once. The HR working group recommends that a new 
working group be established to develop a unified approach to 
system initialization. 


Configuration Options 


Vendors, users, and network administrators all want host software 
that is "plug-and-play". Unfortunately, the working group was 
often forced to require additional configuration parameters to 
satisfy interoperability, functionality, and/or efficiency needs 
[1.2.4 in either RFC]. The working group was fully aware of the 
drawbacks of configuration parameters, but based upon extensive 
experience with existing implementations, it felt that the 
flexibility was sometimes more important than installation 
simplicity. 


Some of the configuration parameters are forced for 
interoperability with earlier, incorrect implementations. Very 
little can be done to ease this problem, although retirement of 
the offending systems will gradually solve it. However, it would 
be desirable to re-examine the other required configuration 
options, in an attempt to develop ways to eliminate some of them. 


Link-Layer Issues: 


(2) 


Braden 


ARP Cache Maintenance 


"Proxy ARP" is a link-layer mechanism for IP routing, and its use 
results in difficult problems in managing the ARP cache. 


Even without proxy ARP, the management dynamics of the IP route 
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cache interact in subtle ways with transport-layer dynamics; 
introducing routing via proxy ARP brings a third protocol layer 
into the problem, complicating the inter-layer dynamics still 
further. 


The algorithms for maintaining the ARP cache need to be studied 
and experimented with, to create more complete and explicit 
algorithms and requirements. 


(3) FDDI Bit-order in MAC addresses 


On IEEE 802.3 or 802.4 LAN, the MAC address in the header uses the 
same bit-ordering as transmission of the address as data. On 
802.5 and FDDI networks, however, the MAC address in the header is 
in a different bit-ordering from the equivalent 6 bytes sent as 
data. This will make it hard to do MAC-level bridging between 
FDDI and 802.3 LAN’s, for example, although gateways (IP routers) 
can still be used. 


The working group concluded that this is a serious but subtle 
problem with no obvious fix, and that resolving it was beyond the 
scope of the HR working group. 


IP-Layer Issues 

(4) Dead Gateway Detection 
A fundamental requirement for a host is to be able to detect when 
the first-hop gateway has failed. The early TCP/IP 


experimentation was based on the ARPANET, which provided explicit 
notification of gateway failure; as a result, dead gateway 


detection algorithms were not much considered at that time. The 
very general guidelines presented by Dave Clark [RFC-816] are 
inadequate for implementors. The first attempt at applying these 


guidelines was the introduction of universal gateway pinging by 
TOPS-20 systems; this quickly proved to be a major generator of 
ARPANET traffic, and was squelched. The most widely used 
implementation of the Internet protocols, 4.2BSD, solved the 
problem in an extra-architectural manner, by letting the host 
wiretap the gateway routing protocol (RIP). As a result of this 
history, the HR working group was faced with an absence of 
documentated techniques that a host conforming to the Internet 
architecture could use to detect dead gateways. 


After extensive discussion, the working group agreed on the 
outline of an appropriate algorithm. A detailed algorithm was in 
fact written down, to validate the discussion in the HR RFCs. 
This algorithm, or a better one, should be tried experimentally 
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and documented in a new RFC. 
(5) Gateway Discovery 


A host needs to discover the IP addresses of gateways on its 
connected networks. One approach, begun but not finished by 
members of the HR working group, would be to define a new pair of 
ICMP query messages for gateway discovery. In the future, gateway 
discovery should be considered as part of the complete host 
initialization problem. 


(6) MTU Discovery 


Members of the HR working group designed IP options that a host 
could use to discover the minimum MTU of a particular Internet 
path [RFC-1063]. To be useful, the Probe MTU options would have 
to be implemented in all gateways, which is an obstacle to its 
adoption. Code written to use these options has never been 
tested. This work should be carried forward; an effective MTU 
choice will become increasingly important for efficient Internet 
service. 


(7) Routing Advice from Gateways 


A working group member produced a draft specification for ICMP 
messages a host could use to ask gateways for routing advice 
[Lekashman]. While this is not of such pressing importance as the 
issues listed previously, it deserves further consideration and 
perhaps experimentation. 


(8) Dynamic TTL Discovery 


Serious connectivity problems have resulted from host software 
that has too small a TTL value built into the code. HR-CL 
specifies that TTL values must be configurable, to allow TTL to be 
increased if required for communication in a future Internet; 
conformance with this requirement would solve the current 
problems. However, configurable parameters are an operational 
headache, so it has been suggested that a host could have an 
algorithm to determine the TTL ("Internet diameter") dynamically. 
Several algorithms have been suggested, but considerably more work 
would be required to validate them. This is a lower-priority 
problem than issues (4)-(6). 


(9) Dynamic Discovery of Reassembly Timeout Time 


The maximum time for retaining a partially-reassembled datagram is 
another parameter that creates a potential operational headache. 


Braden [Page 11] 


RFC 1127 Perspective on Host Requirements October 1989 


An appropriate reassembly timeout value must balance available 
reassembly buffer space against reliable reassembly. The best 
value thus may depend upon the system and upon subtle delay 
properties (delay dispersion) of the Internet. Again, dynamic 
discovery could be desirable. 


(10) Type-of-Service Routing in Hosts 


As pointed out previously, the HR RFCs contain a number of 
provisions designed to make Type-of-Service (TOS) useful. This 
includes the suggestion that the route cache should have a place 
or specifying the TOS of a particular route. However, host 
algorithms for using TOS specifications need to be developed and 
documented. 


(11) Using Subnets 


An RFC is needed to provide a thorough explanation of the 
implications of subnetting for Internet protocols and for network 
administration. 


Transport-Layer Issues: 
(12) RST Message 


It has been proposed that TCP RST (Reset) segments can contain 
text to provide an explicit explanation of the reason for the 
particular RST. A proposal has been drafted [CLynn]. 


(13) Performance Algorithms 


HR-CL contains a number of requirements on TCP performance 
algorithms; Van Jacobson’s slow start and congestion avoidance, 
Karn’s algorithm, Nagle’s algorithm, and SWS prevention at the 
sender and receiver. Implementors of new TCPs really need more 
guidance than could possibly be included in the HR RFCs. The 
working group suggested that an RFC on TCP performance is needed, 
to describe each of these issues more deeply and especially to 
explain how they fit together. 


Another issue raised by the HR RFCs is the need for validation (or 
rejection) of Van Jacobson’s fast retransmit algorithm. 


Application-Layer Issues: 
(14) Proposed FTP extensions 


A number of minor extensions proposed for FTP should be processed 
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and accepted or rejected. We are aware of the following 
proposals: 


(a) Atomic Store Command 


The FTP specification leaves undefined the disposition of a 
partial file created when an FTP session fails during a store 
operation. It was suggested that this ambiguity could be 
resolved by defining a new store command, Store Atomic (STOA). 
The receiver would delete the partial file if the transfer 
failed before the final data-complete reply had been sent. 
This assumes the use of a transfer mode (e.g., block) in which 
end-of-file can be distinguished from TCP connection failure, 
of course. 


(b) NDIR Command 


"NDIR would be a directories-only analogue to the NLST command. 
Upon receiving an NDIR command an FTP server would return a 
list of the subdirectories to the specified directory or file 
group; or of the current directory if no argument was sent. 

The existing NLST command allows user FTPs to implement 
user-interface niceties such as a "multiple get" command. It 
also allows a selective (as opposed to generative) file-naming 
user interface: the user can pick the desired file out of a 
list instead of typing its name." [Matthews] 


However, the interface needs to distinguish files from 
directories. Up to now, such interfaces have relied on a bug 
in many FTP servers, which have included directory names in the 
list returned by NLST. As hosts come into conformance with 
HR-AS, we need an NDIR command to return directory names. 


(c) Adaptive Compression 


It has been suggested that a sophisticated adaptive data 
compression algorithm, like that provided by the Unix 
"compress" command, should be added as an alternative FTP 
transfer mode. 


(15) SMTP: Global Mail Addressing 


While writing requirements for electronic mail, the working group 
was urged to set rules for SMTP and RFC-822 that would be 
universal, applicable not only to the Internet environment but 
also to the other mail environments that use one or both of these 
protocols. The working group chose to ignore this Siren call, and 
instead limit the HR RFC to requirements specific to the Internet. 
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However, the networking world would certainly benefit from some 


global agreements on mail routing. Strong passions are lurking 
here. 


(16) DNS: Fully Replacing hosts.txt 


As noted in HR-AS [AS 6.1.3.8], the DNS does not yet incorporate 
all the potentially-useful information included in the DDN NIC’s 
hosts.txt file. The DNS should be expanded to cover the hosts.txt 
information. RFC-1101 [RFC-1101] is a step in the right 
direction, but more work is needed. 


5. SUMMARY 


We have summarized the results of the Host Requirements Working 


Group, and listed a set of issues in Internet host protocols that 
need future effort. 
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APPENDIX I -- ISSUES FOR FUTURE REVISION 
In order to complete the HR RFCs, it was necessary to defer some 
technical issues. These issues should be considered by the parties 


responsible for the first update of the HR RFCs. 


The issues pending at the time of publication are listed here, in 
order by protocol layer. 


General Issue: 
Error Logging 
The working group felt that more complete and explicit guidance on 
error logging procedures is needed than is presently contained in 
Section 1.2.3 (both HR RFCs). 

Link Layer Issues: 


= Stolen IP Address 


How should a host react when it detects through ARP traffic that 
some other host has "stolen" its IP address? 


IP Layer Issues: 
= "Raw Mode" Interface 


HR-CL could define an optional "raw mode" interface from the 
application layer to IP. 


a Rational Fragmentation 
When a host performs intentional fragmentation, it should make the 
first fragment as large as possible (this same requirement should 
be placed on gateways). 

= Interaction of Multiple Options 
HR-CL does not give specific rules for the interactions of 
multiple options in the same IP header; this issue was generally 
deferred to a revision of the Gateway Requirements RFC. However, 
this issue might be revisited for hosts. 


— ICMP Error for Source-Routed Packet 


It was suggested that when a source-routed packet arrives with an 
error, any ICMP error message should be sent with the 
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corresponding return route. This assumes that the ICMP error 
message is more likely to be delivered successfully with the 
source route than without it. 


= "Strong" IP Options and ICMP Types 


The HR RFCs takes the general approach that a host should ignore 
whatever it does not understand, so that possible future 
extensions -- e.g., new IP options or new ICMP message types -- 
will cause minimum problems for existing hosts. The result of 
this approach is that when new facilities are used with old hosts, 
a "black hole" can result. Several people have suggested that 
this is not always what is wanted; it may sometimes be more useful 
to obtain an ICMP error message from the old host. To quote 
Jeremey Siegel: 


"Ihe basic premise is that if an option is to have any real 
meaning at all within an ’ [upward] compatible’ environment, it 
must be known whether or not the option actually *carries* its 
meaning. An absurd analogy might be programming languages: I 
could make a compiler which simply ignored unknown sorts of 
statements, thereby allowing for future expansion of the 
language. 


Right now, there are four "classes" of options; only two are 
defined. Take one of the other classes, and define it such 
that any options in that class, if unrecognized, cause an ICMP 
error message. Thus anyone who wants to propose a "strong" 
option (one which requires full participation by all systems 
involved to operate correctly) can assign it to that class. 
Options in the current classes may still be passed through if 
they are unknown; only "weak" options will be assigned to these 
classes in the future." 


— Network Mask 


As explained in HR-CL [CL 3.1.2.3], we believe that a possible 
future transition for the interpretation of IP addresses may be 
eased if hosts always treat an IP address as an indivisible 32- 
bit number. However, there are various circumstances where a host 
has to distinguish its own network number. Charlie Lynn has 
suggested that indivisibility can be retained if a host is 
configured with both an address mask (indicating subnetting) and a 
network mask (with network but not subnet bits). 


= WhoAmI Query 


The following requirement is needed: for a multihomed host, a 
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UDP-based application should (must?) be able to query the 
communication layers to obtain a list of all local IP addresses 
for the host. 


= New Destination Unreachable codes 


For each of the new ICMP Destination Unreachable codes defined in 
HR-CL [CL 3.2.2.1], it should be documented whether the error is 
"softt™ or Thartd™, 


= ICMP Error Schizophrenia 


Section 3.3.8 of HR-CL requires a host to send ICMP error 
messages, yet in nearly all individual cases the specific 
requirements say that errors are to be silently ignored. The 
working group recognized this contradiction but was unwilling to 
resolve it. 


At every choice point, the working group opted towards a 
requirement that would avoid broadcast storms. For example, (1) 
ICMP errors cannot be sent for broadcasts, and also (2) individual 
errors are to be silently ignored. This is redundant; either 
provision (1) or (2) alone, if followed, should eliminate 


broadcast storms. The general area of responses to errors and 
broadcast storms could be reassessed and the individual decisions 
reviewed. 


Transport-Layer Requirements: 
- Delayed ACK Definition 
A more precise and complete definition of the conditions for 


delaying a TCP ACK segment may be desirable; see Section 4.2.3.2 
of HR-CL. 


Telnet Requirements: 
7 Flushing Output 


The DISCUSSION in Section 3.2.4 of HR-AS concerns three possible 
ways for a User Telnet to flush output. It would be helpful for 
users and implementers if one of these could be recommended over 
the others; however, when the working group discussed the matter, 
there seemed to be compelling arguments for each choice. This 
issue needs more study. 
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Telnet LineMode Option 


This important new option is still experimental, but when it 
becomes a standard, implementation should become recommended or 
required. 


FTP Requirements: 


Reply Codes 


A number of problems have been raised with FTP reply codes. 


(a) 


(b) 


(c) 


Braden 


Access Control Failures 
Note that a 550 message is used to indicate access control 
problems for a read-type operation (e.g., RETR, RNFR), while a 553 
message is used for the same purpose for a write-type operation 
(e.g., STOR, STOU, RNTO). 


LIST, NLST, and STAT may fail with a 550 reply due to an access 
control violation. 


MKD should fail with a 553 reply if a directory already exists 
with the same name. 


Directory Operations (RFC-959 Appendix II) 
An RMD may result in a 450 reply if the directory is busy. 
Many of the reply codes shown in the text of Appendix II are 
wrong. A positive completion for CWD should be 250. The 521 code 
shown for MKD should be 553 (see above), while the 431 shown for 
CWD should be a 550. 


HELP and SITE Commands 


The positive completion reply to a HELP command should be code 
214. 


HELP or SITE with an invalid argument should return a 504 reply. 
Bidirectional FTP 

The FTP specification allows an implementation in which data 

transfer takes place in both directions simultaneously, although 


few if any implementations support this. Perhaps HR-AS should 
take a stand for or against this. 


[Page 18] 


RFC 1127 Perspective on Host Requirements October 1989 


SMTP Requirements: 
Š Offline SEND 


Some on the working group felt that the SMTP SEND command, 
intended to display a message immediately on the recipient's 
terminal, should produce an error message if delivery must be 
deferred. 


- Header-like Fields 
John Klensin proposed: 


"Header-like fields whose keywords do not conform to RFC822 are 
strongly discouraged; gateways SHOULD filter them out or place 
them into the message body. If, however, they are not removed, 
Internet hosts not acting as gateways SHOULD NOT utilize or 
inspect them. Hence address-like subfields of those fields SHOULD 
NOT be altered by the gateway." 


T Syntax of Received: Line 


The precise syntax of a revised Received: line (see Section 5.2.8 
of HR-AS) could be given. An unresolved question concerned the 
use of "localhost" rather than a fully-qualified domain name in 
the FROM field of a Received: line. Finally, new syntax was 
proposed for the Message Id field. 


Appendix II -- Gateway Issues 
The working group identified a set of issues that should be 


considered when the Gateway Requirements RFC [RFC-1009] ("GR RFC") is 
revised. 


= All-Subnets Broadcast 
This facility is not currently widely implemented, and HR-CL warns 
users of this fact. The GR RFC should take a stand on whether or 
not gateways ought to implement the necessary routing. 


- Rational Fragmentation 


When a gateway performs intentional fragmentation, it should make 
the first fragment as large as possible. 


= Illegal Source Address 


It has been suggested that a gateway should not forward a packet 
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containing an illegal IP source address, e.g., zero. 

= Option Processing 
Specific rules should be given for the order of processing 
multiple options in the same IP header. Two approaches have been 
used: to process options in the order presented, or to parse them 


all and then process them in some "canonical" order. 


The legality should also be defined for using broadcast or 
multicast addresses in IP options that include IP addresses. 


Security Considerations 


A future revision of the Host Requirements RFCs should incorporate a 
more complete discussion of security issues at all layers. 
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